【IAM】権限管理を疎結合！新CDP候補「assumeGroup」パターン
こんにちは、せーのです。 今回はIAMの権限管理について便利な方法をCDP候補「assumeGroup」パターンとして提案させて頂こうと思います。
どういう時に使うのか
例えばEC2のSTOP/START/REBOOTだけの権限を与えたいユーザーがいるとします。これを「operator権限」とします。 通常はIAMユーザーに直接EC2へのpolicyを書いて解決しますね。 でもそれですと他にoperator権限を付けたいユーザーがいた場合、毎回そのpolicyを書き続けないといけません。めんどいですね。
そこでIAM Groupを使ってそれを解決します。つまり、operator権限をもったIAM Group(operatorグループ)を作り、そこに権限をつけたいユーザーを所属させることで皆operator権限を持つ、という方法です。これでIAMユーザーと権限管理が分離しました。
しかしEC2へのoperator権限、と言ってもoperatorグループに権限を与えたいEC2と与えたくないEC2が出てきますよね。例えばWebサーバーのSTOP/START/REBOOT権限は与えたいけど、NATサーバーは触ってほしくない、みたいなことです。インスタンスIDをpolicyに書きまくる？めんどいめんどい。。。
今回はそんな時のためにユーザー側だけではなく、権限対象となるEC2側も権限から分離しよう、というノウハウです。
どうやるの?
方法はとても簡単です。
- 対象となるサービスにTAGをつける
- IAM GROUPに権限を書き、対象となるサービスにTAG名での条件をつける
- 権限を適用させたいIAM USERをそのGROUPに所属させる。
うん、簡単ですね。
なんで[assumeGroup]？
IAMに詳しい方は”assume”と聞いてピンとくるものがあるかと思います。そう、assumeRoleです。 assumeRoleについての詳しい説明はこちらのブログをご覧いただければバッチリかと思います。 assumeRoleはIAM Roleについてある権限をSecurity Token SerivceというAWSプロダクトのAPIを使って一時的にassume、つまり使うことができるという機能です。 今回行うことはIAM Groupに付いているpolicyをユーザーや対象となるAWSサービスにassumeさせるという感じなので、こういう名前にしました。 ※”assume”という単語はいろんな意味があってわかりにくいのですが、ニュアンス的には「根拠は知らんがとにかくそうなる」という感じの単語です。 つまりassumeGroupとはIAMユーザーにとってもEC2側にとっても どこでどういう風に付けられているかはわからないけど、とにかくgroupの持っている権限が持てる様になった、というニュアンスです。まさに疎結合、クラウド的な考え方です。
それでは講釈はこれくらいにして、実際にやってみましょう。
やってみよう
まずEC2を2つ立てます。名前を「Web」「NAT」とします。 そしてそれぞれTagをつけます。Tag名は「ASM_GROUP」としておきます。valueは[OPERATOR][ADMINISTRATOR]にしておきます。WebサーバはOPERATORの人が触り、NATサーバは管理者の人が触る、というわけです。
そしてIAM Groupを作ります。名前はやっぱり「Operator」とします。 このIAMのPolicyにEC2のSTOP/START/REBOOT権限をつけます。
その際にConditionとして「ASM_GROUPがOPERATORのもののみ」という条件をつけます。 これでEC2側のTagを変えるだけでPolicyは一切触らずに権限対象を管理することができます。エレガントですねえ。 最後にユーザーを二人つくり、一人はこのOperatorグループに所属させます。
これでWatsonさんはOPERATOR用であるWebサーバに対して権限を持ちますが、そうではないNATサーバには権限を持ちません。 NanaさんはそもそもOperatorグループではないので権限を持ちません。 ユーザーを入れ替えてみたり、Tag名を変えてみたりして色々試してみてください。
まとめ
いかがでしたでしょうか、「assumeGroup」パターン。 かなり実用的なパターンではないかと思います。 更に実際にお使いになる時には「自分のパスワードを変えられるような権限」「EC2のリストは見えるようにする権限」などを追加でつけておくとより使いやすくなるでしょう。 皆様も「assumeGroup」パターン、是非お使いになってください。
